* Updated Glide code to latest codebase. By default the maximum number of frames Glide will render ahead is throttled to one. This was done to improve gameplay in Quake3. This can be overridden in the voodoo3.var file by using the FX_GLIDE_SWAPPENDINGCOUNT variable.
Fixed Bugs/New Features in beta 2:
* It is no longer possible for 2D games to accidentally use the Glide fullscreen display modes.
* Mode change requests to the 2D driver while Glide is running are no longer honored until Glide is shut down.
Fixed Bugs/New Features in DR3/beta1:
* 400x300 and 512x384 are now supported as pixel doubled modes (Glide only).
* There is now support for a voodoo3.var file, similar to the voodoo2.var file.
* An audio corruption problem has been fixed.
Known issues/bugs with Glide 2 and Glide 3 on MacOS.
* Test 11 is broken until we get new hardware. See note on lfb's below.
* Test 16 is broken (shameless plug stuff not yet implemented for MacOS).
MacOS Voodoo3 Notes
* Attempting to read from the framebuffer directly via grLfbLock() will return data that is byte swapped within each 16-bit word. Use grLfbReadRegion() if possible as it will always do the right thing. This will be fixed on future hardware, but maximum compatibility please use grLfbReadRegion().
* Contrary to the documentation, on big-endian systems pixel values read from the linear framebuffer will be returned in LLLLLLLLLLLLLLLLRRRRRRRRRRRRRRRR format, which is as you would expect on a big endian system.
* Upon receiving a suspend event from MacOS, you should shut down your rendering engine gracefully and call grSstWinClose(). When your app receives a resume event it should then call grSstWinOpen() and restore graphics state, including downloading textures and such. This will do the right thing on both older Voodoo1/Voodoo2 hardware and on future UMA based hardware.
* If you wish to avoid the problems with suspend and remove, consider avoiding WaitNextEvent() and use GetOSEvent() instead. This will run much faster and your game will never lose control of the display.
* Avoid using the passthrough control since it is a no-op on UMA hardware. If you need to use QuickDraw or the standard windowing system, you should call grSstWinClose() and then do what you need to do. As above, after you call grSstWinOpen() to go back to 3D fullscreen mode, you must restore *all* state information including downloading your texture data.
* You *must* use either grTexCalcMemRequired() or query Glide for hardware texture alignment values. Do not assume 8-byte alignment, contrary to what the Glide2.x documentation says. In fact, you should not assume any texture alignment at all, as it is subject to change on future hardware. On Glide2.x you can use grTexCalcMemRequired() to indirectly determine hardware alignment by passing in a very tiny (1 X 1) texture and checking the size returned. This is not recommended, however. Related to this, do not assume that you know how to calculate the amount of memory that will be used by a texture. Again, *please* use grTexCalcMemRequired().
